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ABSTRACT 

The Navy’s IT-21 philosophy when applied to the Navy-wide Intranet poses a significant 
problem: how to best adapt to the requirements of the new standard and still make the most 
of the currently installed network. The integration of Asynchronous Transfer Mode (ATM) 
backbone and desktop networks with legacy equipment and applications is considered in 
this thesis. The most current solution to this dilemma is the use of Local Area Network 
Emulation (LANE). The focus of this thesis is the implementation of LANE over a 
simulated ship-to-shore satellite link. Data throughput is monitored and analyzed to 
determine the optimum configuration. Testing is conducted to examine the advantages of 
routed Emulated Local Area Networks (ELANs) and non-routed ELANs. An inport 
scenario that benchmarks the two ELAN configurations against the Ethernet Virtual LANs 
(VLANs) is discussed. 



V 



THIS PAGE INTENTIONALLY LEFT BLANK 



VI 



TABLE OF CONTENTS 



I. INTRODUCTION 1 

A. THESIS OBJECTIVE 1 

B. THESIS ORGANIZATION 1 

II. LANE BASICS AND CALL ESTABLISHMENT 3 

A. BACKGROUND 3 

B. ADVANTAGES OF USING AN ATM BACKBONE 3 

C. REASONS FOR LANE 4 

1. LANE and ELAN 5 

2. LANE Components 6 

3. Establishing a Call Up Using LANE 9 

III. ESTABLISHING A SHIP-TO-SHORE SIMULATION MODEL 15 

A. BASIC BATTLEGROUP WAN STRUCTURE 15 

B. EQUIPMENT SETUP 16 

1. Physical Layer 17 

2. Data Link Layer 18 

3. The Network Layer 24 

IV. ANALYSIS OF DATA THROUGHPUT OVER AN ATM WAN 31 

A. ANALYSIS SETUP 31 

B. ANALYSIS OF INPORT SCENARIO 33 

C. ANALYSIS OF UNDERWAY SCENARIO 36 

V. CONCLUSION 39 

A. SUMMARY OF WORK 39 

B. FUTURE WORK 39 

vii 



APPENDIX A. INFORMATION TECHNOLOGY FOR THE TWENTY-FIRST 



CENTURY (IT-21) 41 

APPENDIX B. LECS CONFIGURATION FILE, LECS.CFG 45 

APPENDIX C. ASX-200BX COMMAND LINE: CONFIGURATION LANE 
LES>SHOW ADVANCED 47 

APPENDIX D. RAW DATA FROM SOCKET WRENCHER TRIALS 49 

APPENDIX E. PLOTS FOR INPORT SCENARIO 53 

APPENDIX F. PLOTS FOR UNDERWAY SCENARIO 55 

LIST OF REFERENCES 63 

INITIAL DISTRIBUTION LIST 65 



Vlll 



LIST OF FIGURES 



Figure 1. LANE Functioning Within the OSI Model. [6] 5 

Figure 2. ATM Connection Relationships. [8] 9 

Figure 3. VCC’s Connections Within an ELAN. [6] 10 

Figure 4. Configuration Direct VCC Between LEC and LECS. [6] 1 1 

Figure 5. LEC to LES Control Messaging VCCs. [6] 12 

Figure 6. LANE LEC/ BUS Multicast VCC. [6] 13 

Figure 7. LANE LEC to LEC Data Direct VCC. [6] 13 

Figure 8. Sample Battlegroup WAN Scenario 15 

Figure 9. Ship(inport)-to-Shore ATM with Shore-to-Shore Fast Ethernet Connection 16 

Figure 10. LANE Included OSI Model. [3] 16 

Figure 11. Single ELAN Physical Layer Simulation Model 18 

Figure 12. Two ELAN Physical Layer Simulation Model 18 

Figure 13. ForeRunner PCA ATM Adapter 21 

Figure 14. ForeRunner Emulated LAN Adapter 22 

Figure 1 5. Network Dialog Box for Ship’s Server/Router 23 

Figure 16. Detailed IP Addressing Including Netmasks and Default Gateways 24 

Figure 17. Basic IP Address Block Diagram 25 

Figure 18. EPConfig of the Ship’s Server/Router 26 

Figure 19. TCP/IP Properties Dialog Box, IP Address Tab, Ship-to-Ship 27 

Figure 20. TCP/IP Properties Dialog Box, IP Address Tab, Ship-to-Shore 27 

Figure 21. Static Routing Dialog Box 28 

Figure 22. Shore ASX-200BX Assigned IP Addresses 29 

Figure 23. Socket Wrencher Configuration Dialog Box. [ 1 3] 3 1 

Figure 24. Socket Wrencher TCP Echo Synchronous Test Dialog Box. [13] 32 

Figure 25. 1MB Data File [Zero Propagation Delay] 34 

Figure 26. Throughput versus Propagation Delay [0-250 ms] of a 1MB Data File 36 

Figure 27. Throughput versus Propagation Delay [0-5 ms] of a 1MB Data File 37 

Figure 28. Throughput versus Propagation Delay [50-250 ms] of a 1MB Data File 37 



IX 



THIS PAGE INTENTIONALLY LEFT BLANK 



X 



LIST OF TABLES 



Table 1. ATM Basic Characteristics. [4] 4 

Table 2. Ship ASX-200BX Assigned IP Addresses 29 

Table 3. Shore ELAN IP Routing Information 29 

Table 4. Ship ELAN IP Routing Information 29 



XI 



THIS PAGE INTENTIONALLY LEFT BLANK 



ACRONYMS AND ABBREVIATIONS 



ATM 


Asynchronous Transfer Mode 


BUS 


Broadcast and Unknown Server 


DG 


Default Gateway 


ELAN 


Emulated Local Area Network 


ILMI 


Interim Local Management Interface 


IS 


Information Systems 


IT-21 


Technology for the 21st Gentury 


LANE 


Local Area Network Emulation 


LE_ARP 


LAN Emulation Address Resolution Protocol 


LEG 


LAN Emulation Ghent 


LEGS 


LAN Emulation Gonfiguration Server 


LEH 


LAN Emulation Header 


LES 


LAN Emulation Server 


LoS 


Line-of-Sight 


MAG 


Medium Access Gontrol 


NIG 


Network Interface Gard 


NM 


Netmask 


NSAP 


Network Service Access Point 


OSI 


Open Systems Interconnection 


PVG 


Permanent Virtual Gircuit 


QoS 


Quality of Service 


RIP-2 


Routing Information Protocol Version 2 


RRAS 


Routing and Remote Access Service 


SNMP 


Simple Network Management Protocol 


SVG 


Switched Virtual Gircuit 


VGG 


Virtual Ghannel Gonnection 


VLAN 


Virtual LAN 


WAN 


Wide Area Network 



Xlll 



THIS PAGE INTENTIONALLY LEFT BLANK 



XIV 



ACKNOWLEDGMENT 



I would like to take this opportunity to thank the individuals who supported me 
throughout my research and writing of this thesis. Professor John McEachen, thank you ! 
Your encouragement and support were greatly appreciated. Professor Murali Tummala, 
thank you for being my second reader and providing me with the knowledge of ATM 
networks. To the Networking Laboratory team, we have all come a long way. I look 
forward to any opportunity that would allow us to work together in the future. To Luis 
thanks. Your knowledge of Microsoft NT and networking were instmmental to the success 
of this thesis. To Bill Sucevic, Fore Systems technical support representative, thanks for 
assisting me on my ATM configuration issues. To the Administrative support staff, thanks 
for keeping me out of trouble and supporting me during my tour of duty at Naval 
Postgraduate School. Finally, I would like to say thanks to my Fiancee, Jennifer who spent 
many hours typing and keeping me sane. Mom, Dad and Grandpa; you’ve never failed me 
and are always there, thanks for all the prayers and inspiration. 



XV 



THIS PAGE INTENTIONALLY LEFT BLANK 



XVI 



I. INTRODUCTION 



On March 3, 1997, the U.S. Navy promulgated a policy called Information 
Technology for the 21st Century, or IT-21 [1], which stipulated the minimum hardware and 
software requirements for Department of the Navy (DON) Information Systems (IS). rT-21 
was intended to standardize DON-wide IS development, and adherence to the policy’s 
guidelines have been implemented. Each component of the prototype system of this thesis 
currently meets the 11-21 specification with the exception that the host PC’s do not have 
dual PCMCIA/PC card readers. This criterion has no impact on the findings repotted in the 
thesis. 

IT-21 mandates that ATM backbones be utilized within LANs connected throughout 
the Navy (see Appendix A. Section 7. A). It also mandates the minimum standards 
requirements for software (see Appendix A. Section 7. B). Since current legacy software is 
designed for connectionless networking, a dilemma arises. This dilemma and the current 
solution are the focus of this thesis. 

A. THESIS OBJECTIVE 

The objective of this thesis is to design, develop, test and analyze an Emulated Local 
Area Network (ELAN) system. The goal is to document the results of data throughput 
across a simulated ship-to-shore ELAN. Designing such a system serves three primary 
purposes: 

1. Establishment of a working ELAN system within NPS’ Advanced Networking 
Laboratory. 

2. Determination of data throughput for various network designs. 

3. Identification of an optimal network configuration, which provides the best 
throughput given numerous operational scenarios. 

B. THESIS ORGANIZATION 

This thesis is organized as follows. Chapter II briefly discusses the terms and basic 
building blocks of an ELAN. Discussion includes advantages of using an ATM backbone, 
reasons for LAN emulation (LANE), LANE components, and establishing a call set up 
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using LANE. Using the OSI model, Chapter HI presents two simulation models used in 
testing. Each model is created using OC-3 ELANs. A separate legacy 100 Mbps Fast 
Ethernet Virtual LAN (VLAN), is also used to establish benchmark throughput calculations. 

Results of data throughput over ATM and 100 Mbps Fast Ethernet networks with 
results plotted under various conditions are reported in Chapter FV. The throughput 
calculations simulate both an “inport” and two “underway” scenarios. Throughput 
observations of the underway scenarios are compared. Several trials are conducted using 
numerous values for propagation delay, thus simulating various communication link 
possibilities. Chapter V presents conclusions of the work and suggestions for future studies. 

The introduction to the concept of IT-21 is presented in Appendix A. Appendix B 
contains the LAN Emulation Configuration Server configuration file used in creating the 
network setup. A detailed ELAN configuration for all attached LAN Emulation Clients and 
Servers is documented in Appendix C. All raw data used to present the plots contained in 
Appendix E and F are included in Appendix D. Appendix E details the plots used to 
analyze the inport scenario testing while Appendix F displays plots for critical underway 
scenarios. 
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II. LANE BASICS AND CALL ESTABLISHMENT 



A. BACKGROUND 

The majority of enterprise market share at the time of deciding which protocols 
LANE would emulate was determined to be Ethemet/IEEE 802.3 and Token Ring/TEEE 
802.5 LANs. [2] With increases in demand for bandwidth to transfer voice, video and data 
traffic, these technologies are reaching their useful limits. Legacy style networks, such as 
Token Ring and Ethernet, are broadcast oriented in nature. MAC addresses are used to 
differentiate one location from another. Only the destination device with the correct MAC 
address will process the incoming information. Processing slows as the demand for network 
resources, such as server access and transfers, increases; therefore, a new technology is 
needed to help support larger broadband networks. ATM offers an extremely high 
bandwidth alternative. Further, LANE can be implemented at specific points of Ethernet 
congestion. Use of an edge device, discussed in detail in section C, prevents having to 
replace segments of the Ethernet topology within a given LAN. [3] 

B. ADVANTAGES OF USING AN ATM BACKBONE 

The use of ATM provides a more efficient data flow of information among various 
networks. ATM is well suited for high data rate networks with better resource utilization 
due to statistical multiplexing of information. ATM also guarantees “Quality of Service 
(QoS)” for real- time and non-real-time services. Salient features of ATM are listed in 
Table 1. 
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Operating speeds available: 



1.54, 6.3, 25.6, 44.7, 51.8, 100, 155.5 and 622 Mbps with full duplex 
capability. 



Distance: 

Devices supported: 
Latency: 



Architecture: 

Topology: 

Cable: 



Media access method: 



Signaling 

Switched 

Star 

UTP Category 3, 4 and 5; STP; fiber 
Copper- 100 m; fiber-2 Km 

Adapters, hubs, routers, switches, multiplexers and analyzers 
Fixed 



Table 1. ATM Basic Characteristics. [4] 



C. REASONS FOR LANE 

ATM is a non-broadcast, connection-oriented technology, which operates quite 
differently from existing, broadcast, connectionless LANs, such as Ethernet and Token 
Ring. With the standards set forth in IT-21, we are driven to use some type of interface 
between these two different technologies. From the ATM Forum: “The goal of LAN 
Emulation is to present the illusion that one or more ATM ports can be treated as one or 
more 802.x LAN ports.” [5] LANE is the driver software that allows existing application 
software to connect to the ATM protocol. Existing LANs differ from those of ATM in the 
following areas; 

1. The messages may be characterized as connectionless versus the connection- 
oriented approach of ATM. 

2. Broadcast and multicast are easily accomplished through the shared medium of a 



The LANE service enables end systems (i.e., workstations, servers, bridges, etc.) to 
connect to the ATM network while the software applications interact as if they are attached 
to a traditional LAN. Also, this service supports interconnection of ATM networks with 
traditional LANs by means of bridging methods. This allows interoperability between 
software applications residing on ATM-emulated end systems and on traditional LAN end 
systems. 



LAN. 
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The LANE service has proven to be important to the acceptance of ATM since it 
provides a simple and easy means for mnning existing LAN applications in the ATM 
environment. Networking customers demand coexistence between legacy networks and 
higher bandwidth ATM networks. Current uses of ATM include workgroup LANs and 
LAN backbones. Customers expect to continue to use existing LAN applications as they 
migrate to ATM. 



1. LANE and ELAN 



LANE is driver software that imitates LAN services across ATM using ELANs. 
LANE emulates the services of existing LANs across an ATM network. LANE can be 
supported via the software layer in end systems. LANE’s purpose is not to replace existing 
LANs but to bridge the gap for ATM simulating a token ring or Ethernet network where 
higher bandwidth is required. LANE works at the data link layer, level two, of the OSI 
model as will be discussed in detail in Chapter m. The network layer uses LANE to 
connect to the ATM’s adaptation layer as shown in Figure 1. 



Network 

Layer 


Higher Layer, e.g., 
LLC or Bridging 
Relay Function 


Layer 

Management 

Link 


LAN Emulation 
Client 




LLC Mux 




Layer 






Connection 


I 


null-SSCS 


management 


AAL-5 

i 






SSCOP 


i 






ATM 


Physical Layer 


PHY 



Network 



Figure 1. LANE Functioning Within the OSI Model. [6] 



With LANE operating at layer two, it is designed specifically to separate the ATM 
adaptation layer from the network layer. Thus, all interaction between the two is done via 
the LANE layer “interface.” Therefore, the backbone and edge devices are all that need to 
be replaced when switching to ATM. 
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Creating an ELAN allows a group of users to share the same broadcast regardless of 
whether they are connected to ATM directly or through edge devices. The benefit of this 
upgrade is the minimal amount of equipment needed to receive the advantages of ATM. 
Upgrading to ATM does not require total replacement of all network devices and cabling. 
Since each ELAN operates independently across a single broadcast domain, communication 
between ELANs requires routing devices. The major components of an ELAN network 
consist of ATM end systems (i.e., ATM workstations and ATM bridges), each having at 
least one LANE Client (LEC), and LANE services. We will examine each of these 
components in the following discussion. 

2. LANE Components 

a ) LAN Emulation Client (LEC) 

The ATM Forum defines a LEC as follows: “The LEC performs data 
forwarding and address resolution, provides a MAC level emulated Ethemet/IEEE 802.3 or 
IEEE 802.5 service interface to higher level software, and implements the LANE User 
Network Interface (LUNI) interface in order to communicate with other components within 
a single emulated LAN.”[7] Within LANE, host computers with ATM Network Interface 
Cards (NICs) installed along with appropriate LANE software drivers are referred to as 
LECs. Edge devices as stated earlier are also referred to as LECs. Use of edge devices 
prevents having to replace legacy LAN hardware where it is not required. Edge devices use 
LANE drivers to forward information between an ELAN and an existing Ethernet or Token 
Ring segment. All LECs regardless of being an edge device or a host, provide data 
forwarding. They also provide an ATM network service access point (NSAP) address and 
other ATM control functions. 

b) LAN Emulation Services 

LANE services consist of the following components: the LAN Emulation 
Server (LES), Broadcast and Unknown Server (BUS), and LAN Emulation Configuration 
Server (LECS). Together, these three components are responsible for ELAN configuration, 
address resolution, and broadcast and multicast support. 
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(1) The LAN Emulation Server. The ATM Forum’s definition: 
“The LAN emulation servers implement the control coordination function for the emulated 
LAN. The LESs provide a facility for registering and resolving unicast and multicast MAC 
addresses and/or route descriptors to ATM addresses. A LEC is connected to only one LES. 
A LEC may register LAN destinations it represents and/or multicast MAC addresses it 
wishes to receive with its LES. A LEC will also query its LES when the LEC wishes to 
resolve a MAC address and/or route descriptor to an ATM address. The LES will either 
respond directly to the LEC or forward the query to other clients so they may respond.” [7] 
ATM to ATM address resolution is conducted using a network service access point (NSAP) 
address. The LES provides the MAC to NSAP address resolution for each member of the 
local ELAN. LES software can be installed on any device in the ATM network but is 
normally located within a switch. Each LEC registers its MAC and NSAP addresses with 
the LES, allowing the LES to perform MAC-to-NSAP address resolution. The LES accepts 
MAC address queries, translates the MAC addresses into an NSAP address, and responds 
back to the LEC directly. The LES enables a source LEC to establish a communication path 
to a destination LEC upon completion of any address resolution issues. [7] 

(2) Broadcast and Unknown Server. The broadcast unknown server 
supports the broadcast messaging within an ATM network. As defined by the ATM Fomm, 
the BUS “handles data sent by LEC to the broadcast MAC address ('FFFFFFFFFFFF'), 
multicast data, and initial unicast data which are sent by a LEC before the data direct target 
ATM address has been resolved (before a data direct VCC has been established).” [7] 

A LEC sees a single BUS. The multicast server function provided in 
the BUS is required as part of LANE to provide the connectionless data delivery 
characteristics of a shared network to LECs. The main tasks of the BUS are to distribute 
data with multicast MAC addresses and to deliver initial unicast data, where the MAC 
address has not yet been resolved to a direct ATM connection. All broadcast, multicast and 
unknown traffic to and from a LEC passes through this single entity. 

A LEC sends data frames to the BUS, which serializes the frames 
and re-transmits them directly or indirectly to other LECs. 



7 



The BUS implementation may have multiple interfaces, which 
support receiving and forwarding of specific multicast MAC addressed frames over multiple 
VCCs. If a LEG does not need to receive all multicast MAC addressed frames, it may 
inform the LES during initialization. The LES may then selectively forward multicast MAC 
addressed frames to only those LECs that requested them. 

It is standard practice to co-locate the LES and BUS, creating what is 
known as an “intelligent BUS.” The advantage of the intelligent BUS is that the BUS takes 
advantage of the LES address table and routes traffic only to the destination LEC. This 
implementation reduces undesired broadcast traffic and increases efficiency. [7] 

(3) LAN Emulation Configuration Server (LECS). A LECS 
supports the configuration of large broadband networks by assigning each LEC to one or 
more specific ELANs. As defined by the ATM Forum, a LECS “assigns individual LECs to 
different emulated LANs. Based upon its own policies, configuration database and 
information provided by LEC and other devices, a LECS assigns any client which requests 
configuration information to a particular emulated LAN service by giving that client the 
appropriate LES ATM address. This method supports the ability to assign a client to an 
emulated LAN based on either the physical location (ATM address) or the identity of a 
LAN destination, which it is representing. All LECs must be able to obtain information 
from a LECS using the configuration protocol.” [7] The LECS is normally located in an 
ATM switch along with LES and BUS. 

The LECS make configuration assignments based on administrative 
policies, database information, and physical location based on information provided by a 
LEC. After determining eligibility, the LECS provides the LEC with the ATM address of 
their appropriate LES. The LECS maintains a database that contains administrative 
information for each associated ELAN including ELAN type, application type supported, 
and LES address by which each requested LEC must register. 

The LECs register with the LECS in one of the following three 
methods. The first method is through a predefined LECS address at the LEC. The second 
method is through an interim local management interface (ILMI) discovery. ILMI is a 
standard that specifies the use of SNMP in an ATM management information base 
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providing network status and configuration information. The third and final method is 
through a “well-known” address of the LEGS. A “well-known” address is the ATM NSAP 
address specified by the ATM forum. As discussed earlier, the NSAP address enables LECs 
to communicate with the LECS and LES. 

In order to realize emulated connectionless LAN communication in a 
connection oriented ATM environment, LANE servers work together to provide address 
resolution and data forwarding for each attached client. 

3. Establishing a Call Up Using LANE 

LANE supports both switched virtual circuits (SVCs) and permanent virtual circuits 
(PVCs). This is completed using ATM Virtual Channel Connections (VCCs). A VCC is a 
logical connection and is the basic unit of switching within ATM. VCCs are the lowest 
level of logical paths within ATM networks. Figure 2 illustrates the relationship of VCCs 
within ATM’s connection-oriented environment. 




Figure 2. ATM Connection Relationships. [8] 



Within LANE, we are concerned primarily with two categories of VCCs: control 
me.ssaging and data traffic. Figure 3 illustrates the VCC within a simple ELAN, which 
connects two LECs. 
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Traditional 

LAN 



Figure 3. VCC’s Connections Within an ELAN. [6] 



a) Control Messaging 

This type of connection is used for control traffic functions: initialization, 
registration and address resolution. These are briefly described as follows. 

1 . Initialization involves obtaining the NS AP address of the LES, joining or leaving 
an ELAN and declaring if a LEG desires to receive LE_ARP requests for any 
traffic with unregistered destinations. 

2. Registration requires furnishing of all applicable MAC addresses a LEC is setup 
to respond to. 

3. Address resolution requests and replies are used to obtain the ATM address 
associated with LECs with particular MAC addresses. 

There are three distinct control message VCCs used in establishing 
communications of a LEC within an ELAN. The first connection is the LEC to LECS 
configuration direct VCC. The configuration direct VCC is a bi-directional VCC setup by 
the LEC as part of the LECS connection phase and is used to obtain configuration 
information, including the address of the LES [6]. The entity may maintain this VCC while 
participating in the emulated LAN for further queries to its LECS. The configuration direct 
VCC may be used to inquire about a LEC other than the one to which the configuration 
direct VCC is attached. Figure 4 illustrates the connection of the LEC to LECS via the 
configuration direct VCC. 
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Configuration Direct 
VCC 







LAN Emulation 


LAN Emulation 




Configuration Server 


Client (LEC) 




(LECS) 



Figure 4. Configuration Direct VCC Between LEC and LECS. [6] 

The second connection established is the control direct VCC. The purpose 
of this VCC is to maintain communications between the LEC and LES throughout the 
period during which the LEC is a member of the ELAN. This VCC is established during 
the initialization stage when the LEC joins the ELAN. The control direct VCC is a bi- 
directional point-to-point flow to the LES for sending control traffic. The LEC is required 
to accept control traffic from this flow. 

The final control messaging VCC is the control distribute VCC. The ATM 
Forum defines the control distribute VCC as an optional unidirectional point-to-multipoint 
VCC [6]. This VCC is used to distribute control traffic to the LEC. The control distribute 
VCC is normally setup during the initialization phase by the LES. If a setup is directed by 
the LES, the LEC is required to accept the control distribute VCC prior to acceptance into 
the ELAN. Once established, the call must be maintained throughout the entire ELAN 
connection of the attached LEC. Figure 5 illustrates the VCCs functioning between the 
LEC and LES. 
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Figure 5. LEC to LES Control Messaging VCCs. [6] 

b) Data Traffic Messaging 

The second group of VCCs is the data traffic (channel) VCCs. There are 
three types of data connection: multicast send, multicast forward, and data direct [6]. 

The purpose of the multicast send VCC, once established between the source 
LEC and the BUS, is to allow the LEC to transfer multicast traffic to the BUS. In return, the 
BUS uses the channel to send data to the LEC. Upon initial call establishment between two 
LECs the multicast send VCC is used to transfer unicast data while the source LEC awaits 
the LE_ARP reply from the LES. The multicast send VCC is a bi-directional, point-point 
VCC that is maintained throughout the ELAN connection. 

The multicast forward VCC is established immediately following the 
multicast send VCC. The multicast forward VCC is used by the BUS to transfer data to the 
attached LECs. The multicast forward VCC is either point-to-multipoint or unidirectional 
point-to-point. This VCC is established at ELAN setup and is functional prior to allowing 
the LEC to transfer data within the ELAN. The use of the multicast forward and multicast 
send VCCs makes ATM more efficient in that data does not have to wait for a complete 
connection to be obtained before data is actually transferred within the ELAN. The bus 
forwards the unknown traffic to all registered LECs within the ELAN using multicast 
forward VCC’s. Like the multicast send VCC, this connection is active throughout the 
period in which a LEC is connected to the ELAN. Figure 6 illustrates the connection of 
both the multicast send and multicast forward VCCs between the LEC and BUS. 
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Figure 6. LANE LEG/ BUS Multicast VCC. [6] 



The final data traffic VCC is the data direct VCC. The data direct VCC is 
used to transfer unicast traffic between a source and destination pair of LECs. This VCC is 
established upon receipt of the LE_ARP reply message from the LES, which holds the 
NSAP address of the destination LEC. Once established, all traffic between the source and 
destination LECs is done over the data direct VCC. Data direct VCCs are functional for the 
duration of time required to send data traffic. Figure 7 is an illustration of the data direct 
VCC between two LECs. 




Figure 7. LANE LEC to LEC Data Direct VCC. [6] 
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Quality of Service is monitored and enforced from the time of establishment 
to the time of breakdown of the data direct VCC. The multicast traffic within the multicast 
send and multicast forward VCCs is not monitored with regards to QoS; therefore, there is 
no guarantee of service at this point in the call establishment. 

Understanding the call setup and breakdown is important. Recall that the 
connection between any two LECs is maintained throughout the duration of the call via the 
data direct VCC. As more LECs are allowed to enter an ELAN, more data direct VCC’s are 
required to transfer data between stations. Within an ATM network, QoS contracts are 
negotiated prior to allowing a LEC to participate within the ELAN. Therefore, with limited 
bandwidth, the number of participating LECs is potentially limited, thus placing a maximum 
on the number of participants within an ELAN. 

With this in mind, this study focused on the throughput capability of two 
types of ATM WANs. Chapter HI demonstrates the model layout used to conduct testing 
and analysis. 
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III. ESTABLISfflNG A SfflP-TO-SHORE SIMULATION MODEL 



A. BASIC BATTLEGROUP WAN STRUCTURE 

Figure 8 represents a simple battlegroup representation in which multiple ships and 
shore stations may participate within a WAN. Various segments of this scenario will be 
studied in regards to throughput capacities. However, a detailed understanding of the 
hardware and software requirements incorporated in the creation of an ATM WAN should 
be understood to assist in network establishment. 





Figure 8. Sample Battlegroup WAN Scenario. 
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Figure 9 focuses only on the ship-to-shore inport portion described in Figure 8. This 
cloud diagram represents any number of workstations and servers attached to a scalable 
WAN environment. Figure 9 is used in Chapter IV to benchmark the OC-3 ATM network 
to a standard 100 Mbps Fast Ethernet network. The benchmark comparison to Fast Ethernet 
is calculated only in the zero propagation delay trial as Ethernet was not intended for use 
over a wide area. 




Figure 9. Ship(inport)-to-Shore ATM with Shore-to-Shore Fast Ethernet Connection. 



B. EQUIPMENT SETUP 



Equipment setup will be discussed in the context of the physical, data link, and 
network layers of the OSI model displayed in Figure 10. 




Figure 10. LANE Included OSI Model. [3] 
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1. Physical Layer 

The physical layer incorporates all hardware required for use in the simulation 
model. Each of the two domains used similar hardware. The ship domain consists of two 
workstation PCs. One PC is established as the ship’s server/router, and the other is one of 
what could be many shipboard workstations. The server/router is a Dell Dimension XPS 
D266 operating with 196 MB RAM. A FORE systems PCA-200E 2.0.1 (PCI bus) network 
interface card (NIC) is installed for network operation. The workstation is a Dell Dimension 
XPS H266 operating with 98 MB of RAM with PCA-200E 2.0.1 ATM NIC installed. Both 
of the PCs are connected to a FORE systems ASX-200BX ATM switch by SC-SC 
multimode 62.5/125 pm fiber cables. The ASX-200BX utilizes one Intel I960HA processor 
operating over hardware version F with 16 MB DRAM and 4MB of flash memory. 

The shore domain’s server/router is a Dell Dimension XPS Pro200n with 128 MB 
RAM. As within the ship domain, the shore server/router utilizes a FORE systems PCA- 
200E ATM NIC. Also installed is a 3Com 905B-TX Fast Ethernet NIC used for accessing 
the Internet and other shore servers. The shore workstation is a Dell Dimension XPS 
Pro200n operating with 64 MB RAM, and, similar to the ship domain, a FORE PCA-200 
ATM NIC is installed. The shore domain PCs are connected to a FORE systems ASX- 
200BX through the same fiberoptic cabling as used in the ship domain. 

The two domains are physically interconnected via the same multimode fiber as 
discussed above. An Adtech SX-14 data channel simulator is inserted between the most 
remote member of the shore ELAN and its associated server. The SX-14 is installed with 
single mode fiber transmit and receiver interface. This presented a unique problem that was 
overcome through the use of an airgap on the transmit side of the SX-14. The airgap allows 
for enough attenuation loss between the transmitter laser and the multimode fiber to prevent 
overdriving and potentially damaging the receiver’s photo diode. It is understood that an 
airgap is a temporary fix; however, it was decided that the cost of upgrading the two ASX- 
200 BX switches to conclude a long haul or medium haul single mode module was not cost 
effective at $18000 per module. 



17 



Figure 11 is the physical layer simulation model used to demonstrate the single 
ELAN system. Figure 12 is a layout diagram of the physical layer of the simulation model 
of a two-ELAN system. 
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Figure 11. Single ELAN Physical Layer Simulation Model. 



Ship Based ELAN 
ATM Switch 



ADTECH SX/14 
DataCharmel Simiiiatoi 



Slu>re Based ELAII 
ATM Switch 




Windows HT Workstation Ship Sliore 

Ship Baaed LEC Windows NT POC Windows NT PDC 

Ship Based Server/ Router Shore Based Server / Router 



Diagram: By LT Joseph Prisella, USH 
17 July, 1999 



Figure 12. Two ELAN Physical Layer Simulation Model. 

2. Data Link Layer 

A closer look at Figure 10 reveals that it is in the data link layer of the OSI model 
where the LAN emulation layer resides. Several key installation areas are attended to in this 
layer to create the working ELAN environment as in Figure 1 1 and Figure 12. 
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a ) LAN Emulation Server Setup 

The first step in creating an ELAN is configuring the LEGS. Appendix B 
contains the LEGS configuration file used within the simulation model. A line by line 
breakdown of Appendix B is provided to better understand the functionality of the 
LEGS.GFG file. The names of all ELANS that have accept keys must be included in the 
statement: 

Match Ordering: Shore, Ship 

This line of code provides the order in which to apply the accept and reject rules to the 
group.key statement. The groups in the simulation are “shore” and “ship,” and the keys are 
“accept” as denoted by: 

shore accept: xx.xxxx.xx.xxxxxx.xxxx.xxxx.xxxx.xxxxxxxxxxxx.xx 

ship accept: xx.xxxx.xx.xxxxxx.xxxx.xxxx.xxxx.xxxxxxxxxxxx.xx 

where the use of the “don’t care” address 

xx.xxxx.xx.xxxxxx.xxxx.xxxx.xxxx.xxxxxxxxxxxx.xx 

allows for any client to be accepted within an ELAN. The length in bytes of the largest 
frame is specified by: 

Maximum_frame_size: 1516 

Frame selection size options are 1516, 4544, 9234, and 18190. The default for Ethernet is 
1516 and is therefore used throughout the simulation model. [9] The maximum frame size 
calculation for Ethernet is based on the maximum of 1518 octets for the DA (6 octets), SA 
(6 octets), Type/Length (2 octets). Info (1500 octets), and FGS (4 octets) fields. Since 
LANE data frames also includes the 2 octet LANE Header (LEH) (but does not include the 
FGS field), the emulated Ethernet maximum frame size is 1516 octets (LEH, DA, SA, 
Type/Length, and Info fields). This results in 32 ATM cells (48 byte payload per cell) or 
1536 octets including 12 octets of padding and the 8 octet trailer for AAL5. [6] 

The shore ASX-200 BX ATM switch uses NSAP address: 

Shore.Address: 

47.0005 .80. FFE 1 00.0000.F2 1 A.44 A2.002048 1 A44 A2.0 1 
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The same address is also used in the following line of code: 

Shore.BUS_Address: 

47.0005.80. FFE100.0000.F21A.44A2.0020481A44A2.01 

which follows the convention that shore LES and BUS are co-located to create the 
“intelligent BUS” as discussed in the BUS segment of Chapter II. The final line of code 
corresponding to the shore ELAN is the 

Shore.LAN_Name:shore 

which refers to the alias “shore” and is used to associate with the switch NSAP address. The 
ship ELAN code is nearly identical to the shore ELAN code with the exception of the 

Ship. Address: and ship.BUS_Address 

fields, which contain the NSAP address of the ship’s ASX-200 BX ATM switch: 

Ship address: 

47 .0005. 80. FFE 1 00.0000.F2 1 A.3E9 A.0020 1 8 1 A3E9A.02 
Ship.BUS.Adress: 

47 .0005 .80. FFE 1 OO.OOOO.F2 1 A.3E9 A.0020 1 8 1 A3E9 A.02 
The .LAN_name is modified to 

Ship.LAN_name: ship 

It should be noted at this point that the last byte (2 characters) is reserved as the selector 
byte. The shore selector byte has been arbitrarily set to 01, and the ship selector byte has 
likewise been set to 02. With this LEGS configuration file, all LECs wishing to join either 
ELAN must attempt to establish a VCC to the “well-known” LECS address specified as 
47.0079.00.000000.0000.0000.0000.00A03E000001.00 as required by the ATM forum. A 
special note is that 00A03E forms the ATM Forum assigned Organizational Unit Identifiers 
(OUI) octet with 000001 having been allocated by the ATM Fomm. [7] 

The procedure for uploading the LECS. CFG file were followed in 
accordance with the guidelines for configuring an emulated LAN, outlined in section 3.6.3 
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of reference [9], for both ASX-200 BX switches. In Step 2 of the installation, the command 
“configuration Lane LEGS new OXOC-2B LEGS. CFG” was used by default, providing the 
switches with the ATM Forum’s “well-known” LEGS address. Once these steps have been 
completed, the LANE services are functional and awaiting the LEG installations to complete 
the data link layer requirement. 

b ) LAN Emulation Client Setup 

The understanding of the installation of LANE drivers is critical in 
establishing a LANE environment. There are two parts to the installation of FORE ATM 
adapter software. The first step is the installation of the ForeRunner ATM adapter software. 
This software, once loaded, provides several setup options to the administrator. All settings 
for the simulation model were set to default. It is important to note that the fragment size is 
set to appropriately 1536 for Ethernet emulation. Figure 13 is the ForeRunner PGA ATM 
adapter dialog box. Since OC-3 is the means used to connect the NIC to the switch, the 
“OC3 framing: SONET” and the “empty cell insertion: unassigned” options are selected. If 
multiple NICs are installed the adapter’s identifier will reflect the ATM adapter number. 



ForeRunner PCA ATM Adapter 



Tiansmit Buffet Count: 

Transmit Queue size: 

Receive Buffer Count: 

Receive Queue Size: 

Fragment Size: 

Adapter's Identifier: 

'-OCS Framing 

SONET rsDH 

“Empty Cell Insertion 

Unassigned C Idle 

Copyright (c) 1996^1997 FORE Systems, Inc. All rights reserved. 

Figure 13. ForeRunner PCA ATM Adapter. 
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The second step is the loading and configuring of the ELAN adapter drivers. The 
ELAN LECs are defined in this step. Page 5-10 of reference [10] describes in detail the 
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steps taken to complete the installation. Figure 14 is the dialog box display for the 
ForeRunner emulated LAN adapter. The selections of the values described in Figure 14 are 
identical for both the ship and shore workstations. 

The configuration of the shore server LEC requires ATM to be installed as 
adapter 2. Adapter number 1 is a standard 3Com 905B-TX 100 Mbps Fast Ethernet adapter 
used to connect the other VLAN equipment and the Internet. 



The ship server/router is unique in its configuration. The capability of the 
PCA 200-E ATM adapter allows a single adapter card to function over two separate 
ELANs. With this capability, only one LEC onboard ship needs to participate in both the 
ship and shore ELANs to provide the shore services to the ship workstations. The only 
additional step required in establishing the simulation setup is the configuring of the ELAN 
adapter drivers. 
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Figure 14. ForeRunner Emulated LAN Adapter. 



The ship ELAN server/router needs to have the drivers installed twice with 
the manual ELAN selection block as displayed in Figure 14 set to “ship” for one of the 
ELAN adapters and set to “shore” for the other. Figure 15 is the network neighborhood 
adapter window detailing the adapters installed. Note only one ELAN name is allowed per 
each ELAN adapter. By issuing the ASX-200BX command: 



22 




configure LANE LEC> new 

the switch can be added as a participating LEG within the respective ELAN. Appendix C 
describes in detail the following important parameters created during the installation and 
configuration of the ship and shore ELANs: 

1 . ELAN Name. 

2. LES and BUS NSAP addresses. 

3. The LANE type and maximum packet size. 

4. The assigned non-proxy control distribute VCC, proxy control distribute VCC 
and the multicast forward VCC. 

5. The number of LECs assigned to the ELAN. 

6. Each LEG’S NSAP and MAC address and the currently assigned control direct 
VCC. 

7. The switches assigned name and NSAP address, which includes the operator 
assigned selector byte used previously when configuring the switch as a member 
of an ELAN. 




Figure 15. Network Dialog Box for Ship’s Server/Router. 
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3. 



The Network Layer 



The network layer is the third level in the OSI model. Here we can choose TCP/IP, 
NETBEUI or IPX/SPX to bind our ELAN [10]. For the simulation model, TCP/IP has been 
chosen to handle the movement of packets throughout the network. Figure 16 is a diagram 
detailing the IP addresses, netmasks (NM), and default gateways (DG), used in creating the 
simulation model. 
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Figure 16. Detailed IP Addressing Including Netmasks and Default Gateways. 

All IP addresses in the simulation model begin with 131.120. The Advanced 
Networking Laboratory has been restricted to the class ‘C’ level addresses 122.xxx for 
Ethernet networks and 123.xxx for ATM networks. The information in Figure 16 is applied 
to each adapter using the TCP/IP properties dialog box within Microsoft Windows NT 4.0. 
Under the routing tab of the TCP/IP properties dialog box, ‘Enable IP forwarding’ has been 
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selected on both ELAN server and router LECs. With IP forwarding enabled, TCP/IP data 
packets flow through both server/router edge devices. 



Figure 17 is a basic block diagram, which illustrates the IP addressing as 
implemented in the simulation model. 




CO Workstation 

OS: Windows IIT 4.0 Workstation 




OS: Windows IIT 4.0 Workstation OS: Windows IIT 4.0 Server 



Dia^am: Oy LT Joseph Prisella, USIl 
30 July,1»9 



Figure 1 7. Basic IP Address Block Diagram. 



Microsoft’s updated Routing and Remote Access Service (RRAS) version 2 
software supports Routing Information Protocol version 2 (RIP-2). The key advantage to 
operating RIP-2 is the ability to further divide class “C” addresses into smaller subnets. 
RRAS is supported only by Windows NT 4.0 Server. The term server/router is used when 
discussing the ELAN servers as only servers are designed to support the RIP-2 compliant 
routing service. The ship’s ELAN IP addresses are restricted to the 128 upper class ‘C’ host 
addresses through the use of the network mask 255.255.255.128. All devices within the 
ship’s ELAN including the ASX-200BX switch are assigned the IP address range 123.128 
to 123.255. The shore’s ELAN IP addresses are likewise restricted to using only the lower 
128 addresses in the range 123.0 to 123.127, using the same subnet mask. Since the ship’s 
server/router is a member of both the ship and shore ELAN as discussed in the data link 
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layer section, it is assigned IP addresses corresponding to each subnet. Figure 1 8 uses the 
IPConfig command to display the configuration of the ship’s server/router. 




Figure 18. EPConfig of the Ship’s Server/Router. 

The shore server/router was also upgraded to operate the current RRAS version. 
The reason for the upgrade differs from that of the ship’s server/router. The shore 
server/router could effectively use REP-l to route TCP/IP packets within its domain as the 
router crosses the 122 and 123 subnets meeting RIP-1 requirements. The reason then lies in 
the ability to forward TCP/IP packets from the ship’s CO’s workstation to the internet. In 
order to accomplish this, all routers along the route must support RIP-2, or no P packet 
forwarding can be accomplished. 

As previously stated, P packet forwarding is enabled at both server/routers. Each 
server/router is also the designated default gateway for their respective ELAN. This means 
that all ship workstations must have the ship’s server/router P address entered in the default 
gateway section of the Microsoft TCP/P properties dialog box, P address tab, as displayed 
in Figure 19. 
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Figure 19. TCP/IP Properties Dialog Box, IP Address Tab, Ship-to-Ship. 

Figure 20 illustrates the IP address settings for the ship’s server/router properties as a 
member of the ship’s ELAN. 




Figure 20. TCP/IP Properties Dialog Box, IP Address Tab, Ship-to-Shore. 

In the same way a ship’s workstation addresses the ship’s server/router, the ship’s 
server/router addresses the shore’s server/router. Looking from the shore ELAN to the ship 
ELAN, the ship’s server/router appears to the shore’s server/router as just another 
workstation with an assigned IP address and knows nothing of the network hidden behind 
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the ship’s server/router. Figure 21 illustrates the establishment of static routes ensuring 
proper IP traffic flow to and from respective gateways when using RRAS. 
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Figure 21 . Static Routing Dialog Box. 

IP addressing does not only apply to Microsoft NT workstations and servers as 
studied above, but in much the same way the ASX-200 BX was assigned as a LEC, it too 
can be assigned an IP address. The assigning of IP addresses to the ATM switches enables 
administrators to telnet into the switch via remote location. This function allows them to 
remotely load, control and monitor the operation of the ATM switch instead of having to log 
on locally to thi console port of the switch. Once an IP address is assigned, the ASX-200 
BX appears to any workstation within the network as another LEC. 

Figure 22 is the result of typing the configuration IP> show command within the 
shore assigned ASX-200 BX. The ship configuration is nearly identical with the exception 
that el 16 is replaced as shown in Table 2. In both instances, the IP forwarding state is set to 
forwarding. To check the switch IP environment, the command 

configuration ip routosh 

is entered and reveals the details shown in Table 3 and Table 4. The G flag in the tables 
means that it is an indirect route to a gateway [11]. By setting the default destination value 
to the respective ship or shore gateway, all IP traffic is routed to the appropriate 
server/router. 



28 




IfS Telnet “ 


131 . 120 . 123.20 






mnm 






... — 




Opening a 


session for ”127 . 0. 0-1**, please wait... 






Connected 


to ”127. 0.0.1” (asx200bx). 








NETLABSW20 


:;> con 








HETLABSW20 


: : conf iguration> ip 








NETLABSW20 


: rconfiguration ip> sh 








interface 


state address 


netmask 


broadcast 


ntu 


loO 


up 127.0.0.1 


2S5. 0.0.0 


N/A 


n096 


ieO 


down 131.120.123.160 


255-255-255.128 


131 .120.123.255 




asxO 


down 








qaao 


down 








qaal 


down 








qaa2 


down 








qaa3 


down 








el16 


up 131.120.123.20 


255.255.255.128 


131.120.123.127 


1500 


IP Forwarding State: forwarding 








NETLABSW20 


: rconfiguration ip> 









Figure 22. Shore ASX-200BX Assigned IP Addresses. 



Interface State Address Netmask Broadcast MTU 



ell7 up 131.120.123.130 255.255.255.128 131.120.123.255 1500 

Table 2. Ship ASX-200BX Assigned IP Addresses. 

Destination Gateway Metric Interface Flags _ 

default ” 131.120.123.22 1 ' eTl6 *G 

127.0.0.1 127.0.0.1 0 loO 

131.120.123.0 131.120.123.20 0 ell6 

Table 3. Shore ELAN IP Routing Information. 

Destination Gateway Metric Interface Flags 

default 131.120.123.131 1 el 17 G 

127.0.0.1 127.0.0.1 0 loO 

131.120.123.128 131.120.123.130 0 ell7 



Table 4. Ship ELAN IP Routing Information. 

This concludes discussion of the network layer. In this chapter, we have discussed 
the physical layer, data link layer and the network layer. At this point, the simulation model 
is defined and ready for testing. 
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IV. ANALYSIS OF DATA THROUGHPUT OVER AN ATM WAN 



In Chapter HI, we established a ship-to-shore simulation model, and Figure 1 1 and 
Figure 12 illustrated the layout for the single and two (split) ELAN configurations, 
respectively. Figure 9 focused on an inport situation where a ship ATM ELAN was 
connected directly to a shore ELAN. A second shore server using a 100 Mbps Fast Ethernet 
connection was also connected to the shore server. This chapter discusses in detail analysis 
setup, analysis of inport test results, and analysis of underway test results. 



A. ANALYSIS SETUP 



Two software programs were essential in developing the test results. The first 
program was a generic echo server [12], which was started on the shore server/router. The 
echo server’s purpose was to provide a means of replicating packets sent from a 
workstation. The second program. Socket Wrencher [13], was configured to transmit and 
receive TCP packets and determine throughput calculations. Socket Wrencher’s 
configuration dialog box, as displayed in Figure 23, permits the user to input the IP address 
of the device operating the echo server. 



Configuie 



JHosl; 
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iteration: 



100 



Bytes 

j Cl 28 KByte 
C 64 KByte 
! C 1 KByte 



OK 



Cancel 



Figure 23. Socket Wrencher Configuration Dialog Box. [13] 

All trials conducted used the shore’s server/router. When testing the ATM ELANS, 
the “Host” block was set to EP address 131.120.123.21 whereas testing for the Fast Ethernet 
connection was directed to IP address 131.120.122.101. Trials with propagation delay 
greater than 5 ms were run for 20 iterations while all other trials were tested at 100 
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iterations. The “Transmit Bytes” block indicated the amount of data (or file size) to send to 
the echo server in one iteration. Experiments were conducted with transmission sizes of 1 
MB, 128 KB, or 64 KB. 

The next step in performing a Socket Wrencher test was to select the TCP echo 
synchronous test icon, which then displayed the dialog box as in Figure 24. 
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Figure 24. Socket Wrencher TCP Echo Synchronous Test Dialog Box. [13] 



Selection of the “OK” button would start the configured trial run. Socket Wrencher 
is designed to return values for each of the window sizes as displayed in Figure 24. 
Window size refers to the number of bytes that the receiver is willing to accept. The size of 
the receive buffer in general is the maximum size of the advertised window for that 
connection. By default, the window size is limited to a 16-bit field, which limits the 
window size to 65535 bytes maximum[ll]. Window size throughout for this thesis is 
controlled by the use of the Socket Wrencher program. The Socket Wrencher program is an 
application, which is capable of changing the socket buffer size to influence performance. 
Due to problems with the echo service application, the 16-KB window buffer failed to 
function correctly during testing and was not used. The raw data for all mns is contained in 
Appendix D. Many trials used the same Socket Wrencher configuration while varying the 

\ 

propagation delay. Consequently, the TCP synchronous test window was closed after each 
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trial and the Socket Wrencher program restarted after each run. The purpose for the 
shutdown and restart cycle was to reset Socket Wrencher after aborting the program when 
testing went to the 16-KB window buffer size. 

Propagation delay throughout all testing was solely controlled by the Adtech SX-14 
data channel simulator as illustrated in Figure 11 and Figure 12. The recording of 
propagation time as discussed throughout this report is one half of the round trip time. All 
trials used identically set W— > E and E — > W propagation delays as detailed in Appendix D. 
The largest propagation delay tested was set to 250 ms, which is approximately the 
propagation delay between two earth stations communicating via a geosynchronous satellite. 

In summary, throughput calculations displayed on the TCP echo synchronous trial 
dialog box were calculated in the following manner: 

1. The workstations running Socket Wrencher generated and transferred the 
configured number of b)^es. 

2. The packets received at the server were sequentially ordered and sent to the echo 
server application layer program. 

3. The echo server regenerated all received packets and echoed them back to the 
network with the BP address of the originator. 

4. The originating workstation, through the use of the Socket Wrencher program, 
received all packets and determined the throughput for the selected number of 
iterations based on the elapsed amount of time it took to receive all of the echoed 
transmitted application layer data. 

B. ANALYSIS OF INPORT SCENARIO 

Appendix E contains plots for the three different transmitted file sizes produced 
using Socket Wrencher with the SX-14 propagation delay set to zero for the inport scenario. 
A closer analysis of the 1 MB file’s throughput yields some interesting results as detailed in 
Figure 25. Recall that the inport trial was conducted using a single or a split ELAN as well 
as a 100 Mbps Fast Ethernet connection. Figure 25 illustrates that the throughput of 100 
Mbps Fast Ethernet rivals that of a single ELAN operating an OC-3 (155 Mbps) connection. 
Further analysis of plots in Appendix E indicates that the same is true for the 128 KB and 
the 64 KB data files as well. The split ELAN in Figure 25 falls short in throughput 
comparisons against the single ELAN and Fast Ethernet. The best explanation for the 
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shortcoming of a split ELAN with zero propagation delay is due primarily to the extra 
processing time required to transfer TCP packets through the ship’s server/router. 
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Figure 25. 1MB Data FUe [Zero Propagation Delay]. 

Recall from chapter IV section A, throughput tests using Socket Wrencher require 
that a TCP packet be transmitted, received, and regenerated at the server, and then returned 
back through the network. In the split ELAN, a single packet must be segmented and 
reassembled two times within the ship’s server/router. This adds processing time, which 
directly influences throughput as measured by Socket Wrencher. 

Proof of this processing delay can be observed in Figure 25 when comparing the 
single ELAN to the server-server connection. In this trial. Socket Wrencher is run on the 
ship server/router and connects to the shore server, thus bypassing the routing function. 
Chapter IQ states that each of the two server/routers functions using RRAS version 2. RRAS 
version 2 is a program which provides software routing. Much faster hardware routers are 
available though not studied in this thesis. A hardware router’s throughput capacity could 
potentially approximate that of the server-server connection. The use of a software router 
establishes a worst case scenario. Processor speed and available memory also play a role in 
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determining the efficiency of software routing. Additionally, the split ELAN workstation 
traversed two ASX-200 BX switches in reaching the server whereas the single ELAN 
workstation shared a port on the same switch as the server. Figure 25 also compares the 
throughput versus window buffer size. It is can be clearly seen that window buffer size is an 
important element in maximizing throughput during inport scenario. 

An analysis of the plots in Appendix E indicates that larger files are better able to 
take advantage of the larger window buffer size. This analysis may appear to be skewed 
and misleading; however, on closer examination, smaller file size throughput is more 
significantly affected by the TCP requirement of “slow start.” Slow start is defined as the 
rate at which new packets should be injected into the network as set by the rate of 
acknowledgements returned from the receiver end. 

Slow start attaches the “congestion window” to the sliding window. The congestion 
window is initialized to one segment length. This then limits the window size to one 
segment no matter what the advertised receive window buffer size is initially set to. By 
default, the sender can transmit up to the minimum of the congestion window and the 
advertised window. The congestion window provides flow control imposed by the sender 
while the advertised window provides flow control imposed by the receiver. 

The first segment is transmitted, and the sender awaits the acknowledgement from 
the receiver. Once the transmitter receives the acknowledgement, the window size is 
incremented to two segments. When each of the two segments are acknowledged at the 
transmitter, the window is doubled. This process continues until the window buffer size is 
reached. [11] 

Slow start has more of an effect on small file sizes as compared to larger file sizes. 
The smaller file sizes are nearer to completion on exiting slow start than would be a larger 
file size, which is allowed to operate at the advertised window size. 

One of the principal questions of this thesis is to analyze the benefit of operating 
either a single, split, or Fast Ethernet network. The inport graphs in Appendix E suggest 
that the optimum configuration would be to operate all ATM LECs on a single ELAN or 
Fast Ethernet LAN when transferring “small” files using an 8-KB window buffer; however, 
an important factor that must be addressed is the amount of overhead data required to 
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transmit TCP data over ATM. The small file size used by Socket Wrencher is not indicative 
of the benefits of using ATM. Much of the reduction in throughput is attributed to call 
establishment at the TCP and LANE levels. Additional reduction is due to the addition of 
headers and segmentation and reassembly at the ATM, DP, and TCP layers. CaU 
establishment results are averaged over 100 iterations as the data direct VCC discussed in 
(see Chapter II) is not dropped until aU 100 iterations are complete. 

C. ANALYSIS OF UNDERWAY SCENARIO 

The graph of underway results for the 1MB data file is displayed in Figure 26. The 
rapid transition in throughput in the 0 to 5 ms propagation delay range is clarified in Figure 

27. Figure 27 iUustrates the convergence of both the single and the split ELAN as well as 
the 4-KB and 8-KB window buffer size. Once converged at the 5 ms point, aU four plots 
follow the same trend in throughput out to 250 ms of propagation delay as shown in Figure 

28. 
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Figure 26. Throughput versus Propagation Delay [0-250 ms] of a 1MB Data File. 
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Figure 27. Throughput versus Propagation Delay [0-5 ms] of a 1MB Data File. 
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Figure 28. Throughput versus Propagation Delay [50-250 ms] of a 1MB Data File. 



37 



Appendix F contains graphs of all underway trials conducted for all three file sizes 
within Socket Wrencher. In all cases, the throughput for single and split ELANs converges 
within 5 ms of propagation delay for each of the data files transferred. 

In summary, analysis of the underway trials demonstrates that processing delays 
become insignificant as propagation delay becomes more dominant. Note that a 5 ms 
propagation delay equates to 1500 Km or approximately a 900 mile separation between ship 
and server stations. Therefore, for ships at sea out past the line-of-sight (LoS) 
communication range, the benefit of a single ELAN over a split ELAN has been overcome 
by the propagation delay. Consequently, no benefit is gained by placing all LECs within the 
same ELAN. 
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V. CONCLUSION 



A. SUMMARY OF WORK 

The purpose of this thesis was to design, develop, test and analyze an Emulated 
LAN (ELAN) system. The objectives of this thesis as detailed in Chapter I were to establish 
a working ELAN within the NFS Advanced Network Laboratory, to determine the data 
throughput using various network designs, and to identify an optimal network configuration. 

Chapter II laid the foundation for understanding the functionality of LANE. This 
chapter described the functions of each major component of LANE and how they 
interoperate. Chapter HI presented the implementation of a working ELAN. Chapter IV 
utilized the various ELAN implementations in Chapter HI through the use of an echo server 
and the Socket Wrencher software to measure throughput values for both “inport” and 
“underway” scenarios. Results of these measurements are presented in Chapter IV, 
Appendix E and Appendix F to demonstrate throughput limitations based on propagation 
delay, process delay, window buffer size, and data file size. 

In conclusion, this thesis has provided measured results in terms of throughput for 
three separate scenarios. As presented in Chapter IV, a network using software routing was 
the worst-case scenario. Also, if more advanced hardware routing were used, results similar 
to those observed in the server-to-server plot within Figure 25 could be obtained. The 
recommendation of this work in regards to connectivity and throughput would be to operate 
individual units as members of a split ELAN within an ATM network while using hardware 
internetwork routing. The benefit of utilizing this configuration would be easily realized 
during the in-chop process as only a single router would require address modifications as 
compared to an entire network. 

B. FUTURE WORK 

The establishment of an operational split ELAN within the NFS Advanced 
Networking Laboratory has opened the door to several future thesis projects. Some of the 
possible future studies are listed below: 
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1. The use of the Socket Wrencher program in calculating throughput was very 
limiting in the area of file size. Using the underway split ELAN scenario and the 
lab’s EtherPeek network analysis software, a future investigation could 
determine throughput versus propagation delay of a VTC or streaming video 
source. The Advanced Networking Laboratory is outfitted with two Logitech 
QuickCam Pro web cameras to facilitate this study. 

2. The available equipment within the Advanced Networking Laboratory provides 
an excellent setting to study the “man in the middle attack.” Through the use of 
the networking equipment, a miniature Internet could be configured to allow the 
testing and analysis of this attack. 

3. ASX-200BX ATM switches provide an administrator the ability to establish 
“usage parameter controls.” An exploration in configuration and optimization 
could be implemented in the ship and shore ELANs. Testing conducted 
throughout this thesis was under optimal conditions. Further study could 
incorporate the use of the Adtech AX-4000 generator functions to add “bursty 
traffic” into the scenario and determine the throughput in a “noisy” environment. 

4. A computer simulation model of the system described within this thesis can be 
developed and throughput calculations compared to those in Appendix D. 
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APPENDIX A. INFORMATION TECHNOLOGY FOR THE TWENTY-FIRST 

CENTURY aT-21) 



RTTUZYUW RUHPSGG9842 0890945-UUUU— RUWFN AA. 

ZNRUUUUU 

R 300944Z MAR 97 ZYB PSN 077820Q24 
FM CINCPACFLT PEARL HARBOR HI//N00// 

TO ALPACFLT 
ALLANTFLT 

INFO RUENAAA/ASSTSECNAV RDA WASHINGTON Da/C4I// 

RUENAAA/CNO WASHINGTON Da/N00/N09/N095/N2/N4/N41/N43/N46/N6/N6B/ 

N8/N80/N85/N86/N87/N88// 

RUCBCLF/CINCLANTFLT NORFOLK VA//N00/N6// 

RUCBACM/CINCUSACOM NORFOLK VA//J00/J6// 

RHHMUNA/USCINCPAC HONOLULU HI//JOO/J6// 

RHDLCNE/CINCUSNAVEUR LONDON UK//00/N6// 

RULSSEA/COMNAVSEASYSCOM WASHINGTON DO/NOO/N08/PMS335/PMS3 
RUENMED/BUMED WASHINGTON DC//N00// 

RHRMDAB/RUaNAV/COMUSNAVCENT//NOO/N6// 

RUCTPOA/CNET PENSACOLA Fiy/NOO// 

RUEACNP/BUPERS WASHINGTON DO/NOO// 

RUHEHMS/COMMARFORPAa/CG/G6// 

RUCKMAA/COMMARFORLANT//CG/G6// 

RULSSPA/COMSPAWARSYSCOM WASHINGTON Da/N00/N05/PMW17I/PMWI76// 

RUWFADO/NAVSTKAIRWARCEN FALLON NV//N00// 

RULKSDF/COMNAVSECGRU FT GEORGE G MEADE MD//N(Xy/ 

RULSAMX/COMNAVSUPSYSCOM MECHANICSBURG PA//NOO// 

RUWFAFK/COMNAVSPECWARCOM CORONADO CA//N00// 

RULSADG/NRL WASHINGTON DO/NOO// 

RULSWCB/COMNAVCOMTELCOM WASHINGTON DO/NOO/N3// 

RUCOS AO/NAVMASSO CHESAPEAKE VA//NOO/N6// 

RUWFOAAy^CCOSC RDTE DIV SAN DIEGO CA//N433// 

RHHMHAH/CINCPACFLT PEARL HARBOR HI//N00// 

BT 

UNCLAS //N05230// 

ALPACFLT 008/97 

MSGID/GENADMIN/CINCPACFLT/008// 

SUBJ/INFORMATION TECHNOLOGY FOR THE 2F CENTURY/I 
POC/M.R. SCOTT/CDR N6/CINCPACFLT/-/TEL: 808 47 1 -8637// 

POC/D.A. STRAUB/CDR N6/CINCLANTFLT/-/TEL: 757 322-5863// 

RMKS/1. THIS IS THE FIRST IN A SERIES OF JOINT CINCPACFLT AND CINCLANTFLT MESSAGES CONCERNING THE 
DEVELOPMENT AND IMPUEMENTATION OF IT-2L THIS MESSAGE PROVIDES IT-21 HARDWARE/SOFTWARE 
IMPUEMENTATION STANDARDS FOR PROGRAMS INSTALLING INFORMATION SYSTEMS ON FLEET UNITS/BASES AND 
PROVIDES THE FLEET WITH GUIDANCE ON MAINTAINING EXISTING INFORMATION SYSTEMS UNTIL INSTALLATION 
OF rr-21 PRODUCTS. THE 11-21 IMPLEMENTATION STANDARDS OUTLINED BELOW ARE PROMULGATED IN ADVANCE 
OF DON-WIDE GUIDANCE FROM THE DON CHIEF INFORMATION OFHCER (CIO). THE DON CIO WILL PROMULGATE 
DON-WIDE STANDARDS FOLLOWING NEGOTIATION OF ENTERPRISE-WIDE NETWORK OPERATING SYSTEMS AND 
APPLICATIONS. 

2 . BACKGROUND: INFORMATION SUPERIORITY IS THE FOUNDATION OF JOINT VISION 2010 BATTUEFTELD 

DOMINANCE, AS WELL AS THE WARFIGHTING VISION FOR EACH SERVICE. NETWORK WARFARE, ROBUST 
INFRASTRUCTURE AND INFORMATION DISSEMINATION TO DISPERSED FORCES ARE KEY ELEMENTS IN ACHIEVING 
INFORMATION SUPERIORITY. rT-21 IS A FLEET DRIVEN REPRIORITIZATION OFC4I PROGRAMS OF RECORD TO 
ACCEUERATE THE TRANSITION TO A PC BASED TACTICAl/TACTICAL SUPPORT WARFIGHTING NETWORK. THE 
INACTIVATION OF THE CURRENT DOD MESSAGING SYSTEM (AUTODIN) BY DEC 99, WITH NO PLANNED NAVY 
INFRASTRUCTURE REPLACEMENT, MANDATES THE RAPID IMPLEMENTATION OF THIS WARFIGHTING NETWORK. 

3. COMMERCIAL NETWORK OPERATING SYSTEMS (NOS) AND E-MAIL PRODUCTS HAVE ACHIEVED FUNCTIONAL 
PARITY. THE FLEETS CANNOT CONTINUE TO SUPPORT A MULTITUDE OF DIVERSE OPERATING SYSTEMS AND E- 
MAIL PRODUCTS WTIH THEIR OWN TRAINING, OPERATIONAL PRCXEDURES AND TROUBLESHOOTING 
REQUIREMENTS. THE DOD JOINT TECHNICAL ARCHITECTURE (JTA) AND DEFENSE INFORMATION INFRASTRUCTURE 
COMMON OPERATING ENVIRONMENT (DD COE) PROVIDE DOD WITH THE AIS SYSTEM GUIDANCE REQUIRED TO 
TAKE THE NAVY INTO THE 21^ CENTURY. THIS CONVERGENCE OF SOLUTIONS, PROBUEMS AND GUIDANCE 
PROVIDES THE IMPETUS TO ESTABLISH MINIMUM NAVY AIS STANDARDS AT THIS TIME. IMPUEMENTATION OF THIS 
POLICY REQUIRES ALL NON-STANDARD NOS AND E-MAIL PRODUCTS BE REPLACED NLT DEC 99. 
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A. WINDOWS NT SERVER 4.0 IS THE STANDARD FLEET NOS. IT WILL SOON BE FOLLOWED BY WINDOWS NT 5.0. 
WINDOWS NT SERVER 4.0 IS DU COE COMPLIANT. 

B. MS EXCHANGE IS DESIGNATED AS THE STANDARD E-MAIL SOLUTION FOR BOTH FLEETS TO ENSURE AN 
INTEROPERABLE SECURE MESSAGING SYSTEM IS OPERATIONAL PRIOR TO AUTODIN INACTIVATION NLT DEC 99. 

C. MS OFFICE 97 IS DESIGNATED AS THE STANDARD FLEET OFFICE SOFTWARE. 

D. EXPENDITURE OF OPERATING FUNDS TO MAINTAIN EXISTING IT-21 NONCOMPLIANT NOS AND APPLICATIONS 
SHALL BE THE ABSOLUTE MINIMUM NECESSARY TO MEET OPERATING REQUIREMENTS UNTIL IT-21 NOS/SOFTWARE 
IS INSTALLED EVEN IF TEMPORARY LN DEGRADATION OCCURS. SOFTWARE REQUIREMENTS DRIVE HARDWARE 
STANDARDS. HARDWARE AND SOFTWARE PURCHASED TODAY MUST BE CAPABLE OF MEETING MISSION 
REQUIREMENTS THROUGH THE YEAR 2000. 

4. CINCPACFLT AND CINCLANTFLT ARE ACTIVELY WORKING WITH OPNAV ON IT-21 FUNDING AND 
IMPLEMENTATION PLANS. IN GENERAL, AFLOAT IT-21 IMPLEMENTATION WILL BE LINKED TO DEPLOYING 
BATTLEGROUPS AND ASHORE IT-21 WILL BE IMPLEMENTED IN A PHASED APPROACH. SPECIFIC IMPLEMENTATION 
SCHEDULES WILL BE PROMULGATED AT A LATER DATE. CINCPACFLT AND CINCLANTFLT ARE TRANSITIONING TO 
WINDOWS NT 4.0, MS EXCHANGE AND MICROSOFT OFFICE 97. THIS ENVIRONMENT CANNOT BE OPTIMIZED 
WITHOUT 32 BIT OPERATING SYSTEMS, HIGH RESOLUTION DISPLAYS AND MASS STORAGE. ATM BACKBONE LANS 
WITH AT LEAST 100 MBS (TCP/IP)TO THE DESKTOP PC WILL BE INSTALLED ON ALL SHIPBOARD LANS, FLEET 
HEADQUARTERS (CPF. CLF, TYCOMS, GROUP AND SQUADRON COMMANDS) AND SHOULD BE INSTALLED IN THOSE 
SHORE ACTIVITIES THAT SUPPORT TACTICAL OPERATIONS. THIS WILL THEN ALLOW TRANSITION TO ATM-TO- THE- 
DESKTOP PC WHEN THE ATM TECHNOLOGY MATURES. 

5. SYSTEM COMMANDS AND PROGRAM MANAGERS: 

A. NTCSS WILL BECOME THE IT-21 PROGRAM OF RECORD FOR INSTALLATION OF BOTH SECRET AND 
UNCLASSIFIED LANS ONBOARD COMMISSIONED SHIPS. NTCSS (ATIS/SNAP HI) LANS INSTALLED FROM THIS POINT 
ON WILL HAVE AN ATM BACKBONE, 100 MBS (FAST ETHERNET) TO THE DESKTOP PC AND THE 
HARDWARE/SOFTWARE OUTLINED AT THE END OF THIS MESSAGE. THE MIGRATION OF NTCSS LANS TO HIGHER 
CAPACITY LANS WILL REDUCE THE NUMBER OF PC’S DELIVERED DURING INITIAL INSTALLATION. THE TRADE-OFF 
OF QUANTITY FOR FRONT END PC’S IS REQUIRED TO SUPPORT D/-2010 AND AUTODIN INACTIVATION. 

B. SPAWAR IS WORKING WITH NAVSEA TO ENSURE THAT LANS INSTALLED DURING NEW CONSTRUCTION MEET 
THE rr -21 REQUIREMENTS. 

C. APPLICATION PROGRAM MANAGERS SUCH AS JMCIS, NSEPS, TAMPS, AND GCSS SHOULD MIGRATE CURRENT 
APPLICATIONS TO THE DU COE WITH AN IMMEDIATE OBJECTIVE OF OBTAINING PC WORKSTATION ACCESS TO ALL 
APPLICATION DATA ON AN ENTERPRISE LAN. 

D. PROGRAMS INSTALLING INFORMATION SYSTEMS (NEWNET, SMARTLINK, SMARTBASE. TELEMEDICINE, ETC.) 
MUST INSTALL COMPONENTS IN FLEET ACTIVITIES THAT MEET IT-21 STANDARDS AND PROVIDE 
ENTEROPERAB ELITY THROUGHOUT THE WARBGHTING NETWORK. 

6. TYCOMS AND THIRD ECHELON COMMANDS SHALL ENSURE THAT: 

A. SHIPS AND ACTIVITIES INSTALLING NEW LANS. UNDERGOING SIGNIHCANT LAN UPGRADES OR THOSE 
ACTIVITIES WITH STAND ALONE PC’S SHALL INSTALL IT-21 HARDWARE AND SOFTWARE. NEW OR REPLACEMENT 
SHIPBOARD AND SHORE BASED TACTICAL LANS SHOULD HAVE AN ATM BACKBONE WITH AT LEAST 100 MBS (FAST 
ETHERNET) TO THE PC. 

B. SHIPS AND ACTIVITIES WITH EXISTING LANS. WHICH REQUIRE REPLACEMENT OF UNSERVICEABLE 
HARDWARE, SHORT OF A FULL NETWORK UPGRADE, SHALL INSTALL HARDWARE WHICH MEETS IT-21 STANDARDS. 
THE NEW EQUIPMENT MAY NOT BE COMPATIBLE WITH THE EXISTING LAN HARDWARE. CINCPACFLT AND 
CINCLANTFLT BELIEVE THAT ALL AUTOMATED INFORMATION SYSTEMS (AIS) PROCURED MUST BE COMPATIBLE 
WITH THE rr-21 LAN STANDARDS EVEN IF TEMPORARY LAN DEGRADATION OCCURS. THERE IS ONLY SUFHCIENT 
FUNDING TO DO IT RIGHT THE FIRST TIME. 

7. THE IT-21 STANDARDS BELOW REPRESENT FRONT END MARKET TECHNOLOGY. ARE DYNAMIC IN NATURE, AND 
WILL CONTINUE TO BE CLOSELY LINKED TO COMMERCIAL TRENDS. THE STANDARDS LISTED BELOW ARE 
INTENDED TO BE MINIMUM STANDARDS AND WILL BE UPDATED PERIODICALLY. 

A. IT-21 LAN: 

(1) AFLOAT LAN STANDARDS - ATM FIBER BACKBONE, 100 MBPS (FAST ETHERNET) TO THE PC. 

(2) ASHORE TACTICAL AND HEADQUARTERS COMMAND CENTER STANDARD (CPF, CLF, TYCOMS. GROUP AND 
SQUADRON COMMANDS) - ATM BACKBONE, 100 MBPS (FAST ETHERNET) TO THE PC. 

(3) ASHORE TACTICAL SUPPORT COMMAND STANDARDS (BASES) - ATM BACKBONE, 100 MBPS (FAST ETHERNET) 
TO THE PC. 

(4) METROPOLITAN AREA NETWORKS (MAN) SHOULD BE CAPABLE OF SUPPORTING AT LEAST OC-3 (155MBS). 

B. IT-21 SOFTWARE: 

- WINDOWS NT 4.0/5.0 WORKSTATION 

- MS OFFICE 97 PROFESSIONAL (WORD 97. POWERPOINT 97, EXCEL 97, S 
ACCESS 97) 

- IBM ANTI VIRUS (NAVY LICENSE. AVAIL FROM NAVCIRT) 

- MS BACK OFHCE CLIENT 
-MS OUTLOOK 97 

- MS EXCHANGE 5.0 

- MS IMAGE COMPOSER 
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C. rr-21 DATABASES. RELATIONAL DATABASES THAT CAN SUPPORT WEB TECHNOLOGY lAW THE COE (ORACLE, 
S YB ASE, SQL SERVER, ACCESS, ETC) WILL BE USED TO SUPPORT DATA REQUIREMENTS AND APPLICATION 
DEVELOPMENT. ALL PROCESS ENGINEERING INITIATIVES THAT RESULT IN DESIGN/REDESIGN OF A DATA 
COLLECTION/CAPTURE SYSTEM MUST USE COE COMPLIANT RELATIONAL DATABASE MANAGEMENT SYSTEMS 
(RDBMS) SOFTWARE. THIS REQUIREMENT IS PROVIDED TO ENSURE RDBMS INITIATIVES USE COTS APPUCATION 
SOFTWARE. FOR ADDITIONAL INFORMATION ON RELATIONAL DATABASES CONTACT CDR SANDY BUCKLES, CPF 
N67, COMMyDSN (808) 474-6384, NIPRNET mailto:U67@CPF-EMH.CPFNAVY.MIL. 

D. MINIMUM TT-2I PC CAPABILITIES: CPF CAN CURRENTLY PURCHASE THE TT-2I STANDARD PC WITH SOFTWARE 
FOR $3250.00 - $3579.00 - SEE PARA 7(H) AND 7(D. 

- 200 MHZ PENTIUM PRO CPU 

- 64 MB EDO RAM 
-3.0 GB HARD DRIVE 

- 3.5 INCH FLOPPY DISK DRIVE 

- 8X IDE CD-ROM 

- DUAL PCMCIA/PC CARD READER 

- PCI VIDEO W/2MB RAM 

- 17 INCH MONITOR (1280 X 1024) 

- POINTING DEVICE (TRACKBALL OR MOUSE) 

- SOUNDBLASTER (COMPATIBLE) AUDIO CARD WITH SPEAKERS KEYBOARD 

- CPU COMPATIBLE 100 MBPS FAST ETHERNET NIC 

E. STANDARD TT-2 1 LAPTOP WORKSTATION: APPROXIMATELY $5300- 
SEE PARA 7(H). 

-150 MHZ PENTIUM 

- 32 MB EDO RAM 

- 12.1 IN SVGA ACTIVE MATRIX COLOR DISPLAY 
-2.1 GB EIDEHDD 

- 6X INTERNAL CD-ROM 

- MODEM, PCMCIA SLOTS. NIC CARD 

- SMART LITHIUM BATTERY 

F. TT-21 NT FILE SERVER FOR DIRECTORY NETWORK SERVICE: APPROXIMATELY $26K - SEE PARA 7(H). THESE ARE 
MINIMUM SPECDFICATIONS. NEEDS OF THE SPECIFIC NETWORK WILL DICTATE REQUIREMENTS. 

- DUAL 166 MHZ PENTIUM CPU 

- 5 1 2K SECONDARY CACHE MEMORY- 256 MB RAM 

- TWO 4 GB SCSI HDD 
-ONE 6 GB DAT DRIVE 

- ONE 3.5 INCH FLOPPY DISK DRIVE 
-6X SCSI CD-ROM 

- DUAL PCMCIA/PC CARD READER 

- 2 DPT SCSI III CACHING CONTROLLERS (SMARTCACHE 4) 

- PCI VIDEO W/2MB RAM 

- 17 INCH MONITOR (1280 X 1024) 

- POINTING DEVICE (TRACKBALL OR MOUSE) 

- KEYBOARD 

- TWO CABLETRON CPU COMPATIBLE ATM NIC CARDS 

ANTEC DUAL PO\\"ER SUPPLY CASE (HOT SWAPPABLE) 

G. IT-21 FILE SERVER/APPLICATION SERVER: APPROXIMATELY $26K - SEE PARA 7(H). SAME AS IT-21 NT FILE 
SERVER FOR DIRECTORY NETWORK SERVICE WITH THE FOLLOWING CHANGES: 

- CHANGE HDD RQRMT TO FIVE 4 GB DRIVES 

- CHANGE DAT TO 1 8 GB. 

H. PRICES FOR PC TECHNOLOGY ARE CONSTANTLY CHANGING AND CAN VARY GREATLY DEPENDING ON 
METHOD OF PROCUREMENT. FOR EXAMPLE, ON 28 MAR 97 AN IT-21 PC PURCHASED DIRECTLY FROM A VENDOR 
COSTS $3643. GOVERNMENT RATE FOR SMALL PURCHASES (LESS THAN TEN) IS $3579. A BULK PROCUREMENT (MORE 
THAN SEVENTY-FIVE) COSTS $3250. THE ABOVE PRICES INCLUDE SHPPING. BULK PROCUREMENTS SHOULD BE 
MADE THROUGH THE TYPE COMMANDERS WHEN APPROPRIATE. MR. RICK KOOKER, CPF N65, COMM/DSN08O8) 474- 
5882, NIPRNET: U65@CPF-EMH.CPF.NAVY.MIL IS AVAILABLE TO ASSIST TYCOMS WITH AIS PROCUREMENT ISSUES. 

I. AS NETWORK COMPUTER TECHNOLOGY EVOLVES SOME COMMANDS MAY BE ABLE TO TRANSITION TO 
NETWORK COMPUTERS. WHEN CONSIDERING INSTALLATION OF NETWORK COMPUTERS. TOTAL NETWORK COST 
MUST BE EVALUATED. NETWORK COMPUTERS HAVE NOT MATURED SUFFICIENTLY TO IMPLEMENT THEM IN FLEET 
PLATFORMS AT THIS TIME. 

8. WAIVER REQUESTS FROM THE ABOVE STANDARDS SHOULD BE SUBMITTED DIRECTLY TO THE RESPECTIVE 
CPF/CLF N6. POINTS OF CONTACT ARE AS FOLLOWS: 

A. CINCLANTFLT: CDR DEBRA STRAUB AT COMM (757) 322-5863. NIPRNET: maUto:U6@ CLF.NAVY.MIL 

B. CINCPACFLT: CDR MIKE SCOTT AT COMM (808) 474-7860, NIPRNET:U6@ CPF-EMH.CPF.N A VY.MILy/ 

BT 

#9842 

NNNN 
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APPENDIX B. LEGS CONFIGURATION FILE, LECS.CFG 



# 

# The search ordering of ELAN names 

# 

Match.Ordering: shore, ship 

# 

.Maximum_Frame_Size: 1516 

# 



shoreAccept: 


xx.xxxx.xx.xxxxxx.xxxx.xxxx.xxxx.xxxxxxxxxxxx.xx 


shoreAddress: 


47.0005. 80.FFE 1 00.0000. F2 1 A.44 A2.002048 1 A44 A2.0 1 


shore .BUS_Address: 


47.0005. 80.FFE 1 00.0000.F2 1 A.44A2.002048 1 A44A2.0 1 


shore.LAN_Name; 

# 


shore 


shipAccept; 


xx.xxxx.xx.xxxxxx.xxxx.xxxx.xxxx.xxxxxxxxxxxx.xx 


shipAddress: 


47.0005.80.FFE 100.0000.F2 1 A.3E9 A.0020 1 8 1 A3E9A.02 


ship.BUS_Address: 


47.0005 . 80.FFE 1 00.0000.F2 1 A. 3E9 A.0020 1 8 1 A3E9A.02 


ship.LAN_Name: 


ship 
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APPENDIX C. ASX-200BX COMMAND LINE: CONFIGURATION LANE 

LES>SHOW ADVANCED 

NETLABSW20:;configuration lane Ies> sh advanced 

ELAN Name: "shore" 

LES : 47.0005.80.FFE 1 00.0000.F2 1 A.44A2.002048 1 A44A2.0 1 

BUS : 47.0005 . 80.FFE 1 OO.OOOO.F2 1 A.44A2.002048 1 A44A2.0 1 

LAN Type: Ethemet/IEEE 802.3 Maximum Data Frame Size: 1516 

Non-proxy Control Distribute VCC: 0.74 
Proxy Control Distribute VCC: 

Multicast Forward VCC: 0.76 

Number of local clients: 4 

LEC #1 at 47.0005.80.FFE100.0000.F21 A.44A2.00204804EC43.00 (vl, non-proxy) 
00-20-48-04-EC-43 -> 47.0005.80.FFE100.0000.F21 A.44A2.00204804EC43.00 
Control Direct VCC: 0.73 

LEC #2 at 47.0005.80.FFE100.0000.F21A.44A2.00204804ED54.01 (vl, non-proxy) 
00-20-48-04-ED-54 -> 47.0005.80.FFE100.0000.F21 A.44A2.00204804ED54.01 
Control Direct VCC: 0.78 

LEC #3 at 47.0005.80.FFE100.0000.F21 A.3E9A.00204804EA93.02 (vl, non-proxy) 
00-20-48-04-EA-93 -> 47.0005.80.FFE100.0000.F21A.3E9A.00204804EA93.02 
Control Direct VCC: 0.80 

LEC #4 at 47.0005.80.FFE100.0000.F21 A.44A2.0020481 A44A2.10 (vl, non-proxy) 
00-20-48- 1A-44-A2 -> 47.0005.80.FFE100.0000.F21A.44A2.002(H81A44A2.10 
Name: SHORE 
Control Direct VCC: 0.85 
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ELAN Name: "ship" 

LES: 47.0005.80.FFE100.0000.F21A.3E9A.0020481A3E9A.02 

BUS: 47.0005.80.FFE100.0000.F21 A.3E9A.002048 1 A3E9A.02 

LAN Type: Ethemet/IEEE 802.3 Maximum Data Frame Size: 1516 
Non-proxy Control Distribute VCC: 0.90 
Proxy Control Distribute VCC: 

Multicast Forward VCC: 0.92 
Number of local clients: 3 

LEC #1 at 47.0005. 80.FFE100.0000.F21A.3E9A.00204804ED46.00 (vl, non-proxy) 
00-20-48-04-ED-46 -> 47.0005.80.FFE100.0000.F21 A.3E9A.00204804ED46.00 
Control Direct VCC: 0.89 

LEC #2 at 47.0005.80.FFE100.0000.F21A.3E9A.00204804EA93.00 (vl, non-proxy) 
02-20-48-04-EA-93 -> 47.0005.80.FFE100.0000.F21 A.3E9A.00204804EA93.00 
Control Direct VCC: 0.94 

LEC #3 AT 47.0005.80.FFE100.0000.F21A.3E9A.0020481A3E9A.1 1 (vl, non-proxy) 
00-20-48- 1A-3E-9 A -> 47.0005.80.FFE100.0000.F21A.3E9A.0020481A3E9A.1 1 
Name: SHIP 

Control Direct VCC: 0.99 
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APPENDIX D. RAW DATA FROM SOCKET WRENCHER TRIALS 



Zero Propagation Delay 



1M 




Window 


Single 


Split 


Ethernet 


ShipServ 


1 


841.59 


603.27 


827.062 


791.203 


2 


1293.33 


960.561 


1250.402 


1230.509 


4 


1828.89 


1298.65 


1729.779 


1779.113 


8 


2438.097 


1545.753 


2388.573 


2293.334 


128K 




Window 


Single 


Split 


Ethernet 


ShipServ 


1 


853.333 


640.00 


826.027 


788.48 


2 


1351.68 


648.907 


1331.2 


1280 


4 


1904.64 


1464.32 


1781.76 


1761.28 


8 


2054.702 


1751.04 


2074.81 


2050.979 


64K 




Window 


Single 


Split 


Ethernet 


ShipServ 


1 


866.16 


686.96 


849.92 


814.08 


2 


1042.432 


936.96 


1040.756 


1035.729 


4 


1077.62 


1099.188 


1082.647 


1080.971 


8 


1101.079 


1072.593 


1104.43 


1099.403 



10msec Propagation Delay 


1M 






Window 


Single 


Split 


1 


48.178 


47.163 


2 


93.388 


91.982 


4 


181.614 


175.826 


8 


189.692 


184.336 


128K 




Window 


Single 


Split 


1 


47.741 


46.816 


2 


92.889 


90.865 


4 


169.354 


163.446 


8 


174.545 


170.667 


64K 




Window 


Single 


Split 


1 


47.543 


46.343 


2 


91.927 


88.436 


4 


156.038 


152.381 


8 


162.133 


158.476 



5msec Propagation Delay 



1M 




Window 


Single 


Split 


1 


86.732 


87.72 


2 


160.421 


165.39 


4 


300.167 


311.312 


8 


332.683 


337.234 


128K 




Window 


Single 


Split 


1 


84.48 


87.374 


2 


164.103 


164.759 


4 


292.571 


290.743 


8 


319.391 


314.514 


64K 




Window 


Single 


Split 


1 


88.99 


87.721 


2 


172.373 


162.133 


4 


294.4 


273.067 


8 


307.2 


294.4 



20msec Propagation Delay 



1M 




Window 


Single 


Split 


1 


24.795 


24.53 


2 


49.118 


48.39 


4 


95.504 


94.008 


8 


97.86 


96.112 


128K 




Window 


Sin^e 


Split 


1 


22.311 


24.381 


2 


48.422 


47.176 


4 


88.858 


87.559 


8 


90.46 


89.246 


64K 




Window 


Single 


Split 


1 


24.381 


24.154 


2 


47.543 


47.1 


4 


82.38 


81.067 


8 


84.021 


82.051 
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50msec Propagation Delay 



100msec Propagation Delay 



1M 




Window 


Single 


Split 


1 


10.094 


10.056 


2 


20.094 


19.983 


4 


39.502 


39.133 


8 


39.896 


39.606 


128K 




Window 


Single 


Split 


1 


10.025 


9.985 


2 


19.771 


19.648 


4 


36.704 


36.411 


8 


36.904 


36.704 


64K 




Window 


Single 


Split 


1 


9.942 


9.904 


2 


19.907 


19.414 


4 


33.748 


33.528 


8 


34.023 


33.968 



150msec Propagation Delay 



1M 




Window 


Single 


Split 


1 


3.392 


3.388 


2 


6.769 


6.754 


4 


13.308 


12.948 


8 


13.365 


13.132 


128K 




Window 


Single 


Split 


1 


3.368 


3.364 


2 


6.682 


6.637 


4 


12.269 


12.31 


8 


12.365 


12.303 


64K 




Window 


Single 


Split 


1 


3.341 


3.337 


2 


6.577 


6.566 


4 


11.353 


11.116 


8 


11.297 


11.423 



1M 




Window 


Single 


Split 


1 


5.078 


5.068 


2 


10.122 


10.092 


4 


19.959 


19.844 


8 


19.997 


19.988 


128K 




Window 


Single 


Split 


1 


5.039 


5.031 


2 


9.99 


9.968 


4 


18.509 


18.202 


8 


18.468 


18.534 


64K 




Window 


Single 


Split 


1 


5.002 


5.001 


2 


9.832 


9.686 


4 


16.817 


16.861 


8 


17.125 


17.097 



200msec Propagation Delay 



1M 




Window 


Single 


Split 


1 


2.546 


2.544 


2 


5.083 


5.072 


4 


10.021 


9.798 


8 


10.061 


9.962 


128K 




Window 


Single 


Split 


1 


2.529 


2.527 


2 


5.012 


4.983 


4 


9.301 


9.12 


8 


9.271 


9.276 


64K 




Window 


Single 


Captain 


1 


2.529 


2.507 


2 


5.012 


4.935 


4 


9.301 


8.537 


8 


9.271 


8.517 
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250msec Propagation Delay 1MByte File 8KByte Buffer 



1M 










Delay [msec] 


Single 


Split 


Window 


Single 


Split 






0 


2438.097 


1545.753 


1 


2.038 


2.036 






0.5 


1599.192 


1348.253 


2 


4.066 


4.062 






1 


1210.548 


1021.411 


4 


2.892 


2.887 






1.5 


908.041 


807.375 


8 


4.701 


4.264 






2 


734.73 


677.681 


128K 










2.5 


637.292 


581.588 


Window 


Single 


Split 






3 


547.293 


507.066 


1 


1.949 


2.023 






3.5 


484.001 


450.032 


2 


3.868 


4.005 






4 


426.944 


404.439 


4 


4.934 


4.756 






4.5 


390.248 


368.626 


8 


5.97 


6.053 






5 


319.391 


314.514 


64K 










10 


189.692 


184.336 


Window 


Single 


Split 






20 


97.86 


96.112 


1 


1.936 


1.973 






50 


39.896 


39.606 


2 


3.79 


3.861 






100 


19.997 


19.988 


4 


6.68 


6.818 






150 


13.365 


13.132 


8 


6.889 


6.889 






200 


10.061 


9.962 












250 


4.701 


4.264 


1 MByte File 4KByte Buffer 


2KByte Buffer 


1KByte Buffer 




Delay [msec] 


Single 


Split 


Single 


Split 


Single 


Split 




0 


1828.89 


1298.65 


1293.33 


960.561 


841.59 


603.27 




0.5 


1227.288 


1016.667 


780.953 


649.067 


456.65 


390.662 




1 


953.138 


808.885 


562.758 


493.384 


313.172 


281.865 




1.5 


779.429 


676.812 


437.33 


396.259 


234.444 


220.762 




2 


610.448 


578.505 


359.45 


331.556 


195.057 


181.597 




2.5 


556.059 


507.258 


297.401 


285.237 


161.388 


153.381 




3 


488.263 


450.413 


266.036 


249.835 


141.521 


133.871 




3.5 


439.277 


404.401 


236.184 


222.974 


123.104 


118.388 




4 


393.49 


368.359 


211.688 


200.893 


110.836 


106.187 




4.5 


357.4 


336.62 


191.647 


182.506 


99.509 


96.064 




5 


292.571 


290.743 


164.103 


164.759 


84.48 


87.374 




10 


181.614 


175.826 


93.388 


91.982 


48.178 


47.163 




20 


95.504 


94.008 


49.118 


48.39 


24.795 


24.53 




50 


39.502 


39.133 


20.094 


19.983 


10.094 


10.056 




100 


19.959 


19.844 


10.122 


10.092 


5.078 


5.068 




150 


13.308 


12.948 


6.769 


6.754 


3.392 


3.388 




200 


10.021 


9.798 


5.083 


5.072 


2.546 


2.544 




250 


2.892 


2.887 


4.066 


4.062 


2.038 


2.036 
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128KByte File 8KByte Buffer 


Delay [msec] 


Single 


Split 


0 


2054.702 


1751.04 


5 


319.391 


314.514 


10 


189.692 


170,667 


20 


97.86 


89.246 


50 


36.904 


36.704 


100 


18.468 


18.534 


150 


12.365 


12.303 


200 


9.271 


9.276 


250 


5.97 


6.053 


128 KByte File 4KByte Buffer 


Delay [msec] 


Single 


Captain 


0 


1904.64 


1464.32 


5 


292.571 


290.743 


10 


181.614 


163,446 


20 


95.504 


87.559 


50 


36.704 


36.411 


100 


18.509 


18.202 


150 


12.269 


12.31 


200 


9.301 


9.12 


250 


4,934 


4.756 


128 KByte File 2KByte Buffer 


Delay [msec] 


Single 


Split 


0 


1351.68 


648,907 


5 


164.103 


164.759 


10 


93.388 


90.865 


20 


49.118 


47.176 


50 


19.771 


19.648 


100 


9.99 


9.968 


150 


6.682 


6.637 


200 


5.012 


4.983 


250 


3,868 


4.005 


128 KByte File 1KByte Buffer 


Delay [msec] 


Single 


Split 


0 


853.333 


640.00 


5 


84.48 


87.374 


10 


48.178 


46.816 


20 


24.795 


24.381 


50 


10.025 


9.985 


100 


5.039 


5.031 


150 


3.368 


3.364 


200 


2.529 


2.527 


250 


1.949 


2.023 



64KB] 


yte File 8KByte Buffer 


Delay [msec] 


Single 


Split 


0 


1101.079 


1072.593 


5 


307.2 


294.4 


10 


162.133 


158.476 


20 


84.021 


82.051 


50 


34.023 


33.968 


100 


17.125 


17.097 


150 


11.297 


1 1 .423 


200 


9.271 


8,517 


250 


6.889 


6.889 


64 KB 


yte File 4KByte Buffer 


Delay [msec] 


Single 


Split 


0 


1077.62 


1099.188 


5 


294.4 


273.067 


10 


156.038 


152.381 


20 


82.38 


81.067 


50 


33.748 


33.528 


100 


16.817 


16.861 


150 


11.353 


11.116 


200 


9.301 


8.537 


250 


6.68 


6.818 


64 KB] 


yte File 2KByte Buffer 


Delay [msec] 


Single 


Split 


0 


1042.432 


936.96 


5 


172.373 


162.133 


10 


91.927 


88.436 


20 


47.543 


47.1 


50 


19.907 


19,414 


100 


9.832 


9.686 


150 


6.577 


6.566 


200 


5.012 


4.935 


250 


3.79 


3.861 


64 KB 


yte File 1 KByte Buffer 


Delay [msec] 


Single 


Split 


0 


866.16 


686.96 


5 


88.99 


87.721 


10 


47.543 


46.343 


20 


24.381 


24.154 


50 


9.942 


9.904 


100 


5.002 


5.001 


150 


3.341 


3.337 


200 


2.529 


2.507 


250 


1.936 


1.973 
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Throughput [KBytes/sec] Throughput [KBytes/sec] 



APPENDIX E. PLOTS FOR INPORT SCENARIO. 



1MByte data file size [Zero Propagation Delay] 




Single ELAN 
—•—Split ELAN 

Ethernet VLAN 
— K — Server to Server 



128KB data file size [Zero Propagation Delay] 




— ♦—Single ELAN 
—■—Split ELAN 
4 Ethernet VLAN 
— X — Server to Server 
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64KB data file size [Zero Propagation DeSay] 




Window Buffer Size [Kbyte] 



— 4‘ — Single ELAN 
— Split ELAN 
. Ethernet VLAN 
—X — Server to Server 
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Throughput [KBytes/sec] Throughput [KBytes/sec] 



APPENDIX F. PLOTS FOR UNDERWAY SCENARIO 



Throughput of a 1MB file with 1 and 2 KB Window 
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Propagation Delay [msec] 



•SlPS(®ELANw/ 

2Kw<ndov 



Split E LAN w/ 
2K windcw 



Slnc^oELANw/ 
IK window 

Split ELANw/ 
IK window 



Throughput of a 1 M B file w ith 1 and 2 KB Window 
[0-5 msec Propagation Delay] 
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Throughput [KBytes/sec] Throughput [KBytes/sec] 



Throughput of a IMBfile with 1 and 2 KB Window 
[50-250 msec Propagation Delay] 
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Throughput of a 1MB file with 4 and 8 KB Window 
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Throughput [KBytes/sec] Throughput [KBytes/sec] 



Throughput of a 1M B file with 4 and 8 KB Window 
[0 > 5 m sec Propagation Delay] 




— SIndoELANw/ 
SKVvtnctw 
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Propagation Delay [msec] 



Throughput of a 1MB file with 4 and 8 KB Window 
[50-250 msec Propagation Deiay] 
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Throughput [KBytss/sac] 



Throughput of a 12& KB flia with 1 and 2 KB Window 
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Throughput of a 12S KB tile with 1 and 2 KB Window 
[50*250 nts Propagation Delay] 
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-Spin ELANw/ 
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i 






■M 






Throughput [KBytos/soc] Throughput [KBytes/secl 



Throughput of a 128 KB fllo with 4 and 8 KB Window 




— Single ELAN w/ 
8K window 

—•—Split ELAN w/ 
8K window 

Single ELAN w/ 
4K window 

Split ELAN w/ 
4K window 



Throughput of a 128 KB flla with 4 and 8 KB Window 
[50*250 ms Propagation Dolay] 




100 160 200 
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Throughput of a 64 KB file with 1 and 2 KB Window 
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[50-250 wa Propagation Delay] 
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Throughput [KBytes/sec] Throughput [KBytes/sec] 



Throughput of a 64 KB file with 4 and 8 KB Window 




—♦—Single ELAN w/ 
8K window 

-•-Split ELANw/ 
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- Single ELAN w/ 
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Throughput of a 64 KB file with 4 and 8 KB Window 
[50-250 ms Propagation E)elay] 
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